Method for secure single-packet remote authorization

ABSTRACT

A method for secure single-packet remote authorization using a single packet authorization (SPA) server on a host system that passively monitors the network for connection attempts and anonymously accept or rejects said attempts depending on whether a valid SPA packet is detected, an SPA client on a client system that is responsible for generating the appropriately encrypted SPA packet in order to gain access to services on the host, and a particular packet format sent from the client to the host to gain access. The packet format is encrypted and non-replayable by virtue of 16 bytes of random data in every message, and an MD5 sum that is a hash function of the random data (made via any known hashing function). The SPA server stores the MD5 sum of every valid SPA packet that it monitors and flags any duplicate access attempts using the same MD5 hash as a previously monitored packet, in which case the SPA server treats the packet as being generated by a malicious attempt to replay the original packet.

CROSS-REFERENCE TO RELATED APPLICATION(S)

The present application derives priority from U.S. ProvisionalApplication No. 60/784,701 filed Mar. 22, 2006.

BACKGROUND OF THE INVENTION

(1) Field of the Invention

The present invention relates to distributed information protection andnetwork security and, more particularly, to a method for securesingle-packet remote authorization using a daemon that passivelymonitors a network for a specially constructed encrypted packet andanonymously accepts or rejects subsequent connection attempts based onthe characteristics of said packet.

(2) Description of Prior Art

Network technology is invaluable for sharing resources. However,connecting a computer or network to the Internet is a risky proposition.There is a high probability that eventually, someone will gainunauthorized access. To exploit a server-side application vulnerability,an intruder needs to gain access to an open port leading into thesystem, or trick the host system into opening one (through shellcodethat exploits a software vulnerability and opens a backdoor into thesystem for example). This requires a combination of the host system'sunique IP (Internet protocol) address, and the ability to talk to theserver's TCP (Transmission Protocol) or UDP (User Datagram Protocol)stack and corresponding ports that serve as the door into the hostsystem.

Firewalls help to prevent the ability of attackers to exploit softwarevulnerabilities through the use of port and protocol filtering tominimize server access from arbitrary IP addresses, and also through theuse of NAT (network address translation) for protected internal hosts.Unfortunately, conventional firewalls operate under a fixed rulesetwhich, if predicted or examined through various scanning methods, canoffer little protection for vulnerable services. Consequently, a varietyof more robust authorization techniques have evolved to increasesecurity.

For example, U.S. Patent Application Nos. 20050182968 and 20030140248both by Izatt et al. show an “Intelligent firewall” that analyzesincoming packets to determine whether or not they are acceptable toforward on to a destination in the network. If the packet is notacceptable, access to the network is denied and the packet is droppedwith no denial of access message being sent to the source of the packet.As a result, there is no detectable response to the sender of deniedaccess from the firewall.

United States Patent Application 20050240994 by Burcham published Oct.27, 2005 shows a method for maintaining network access and security thatuses a perimeter client and a perimeter server.

“Port knocking” is a method of externally opening ports on a firewall bygenerating a connection attempt on a set of prespecified closed ports.Once a correct sequence of connection attempts is received the firewallrules are dynamically changed to allow the computer that sent theconnection attempts to connect over specified port(s). Port knocking istypically implemented by a daemon (a computer program that runs in thebackground) that watches the firewall log file for connection attemptsand that modifies the firewall configuration accordingly. The port knocksequence itself is a secret handshake comprising any number of TCP, UDPpackets to numbered ports on the host system. The complexity of theknock can be anything from a simple ordered list of ports to a complextime-dependent, source-IP-based encrypted string. The portknock daemonlistens for knocks on certain ports (either via the firewall log or bypacket capture) and allows access accordingly. When the concept of portknocking was announced in 2003 (Krzywinski, M., Port Knocking: NetworkAuthentication Across Closed Ports, SysAdmin Magazine 12: 12-17; 2003),many competing implementations were rapidly developed. There are nowover 30 different software projects dedicated to various implementationsof port knocking. The two most important characteristics of portknocking in terms of enhancing security are: 1) the passivecommunication of authentication information from a remote system to thehost system, with no return of data (anyone who casually scans thetarget system will not be able to tell that there is any serverlistening on the ports protected by the knock server); and 2) the serverside use of a packet filter to intercept all attempts to connect withthe server that are not associated with a valid port knocking sequence.Consequently, even if an attacker possesses the host system's IPaddress, TCP and UDP ports that serve as the door to the host system arecompletely inaccessible without first issuing a valid knock sequence.

The present inventor has implemented an open-source daemon called fwknop(Firewall Knock Operator), which supports an entirely new mechanism fornetwork authentication and authorization called Single PacketAuthorization that requires only a single encrypted packet in order togain access to protected services. This new mechanism offers manyadvantages over both shared and encrypted port knock sequences asdiscussed below.

Unfortunately, port knocking is not designed to provide bullet-proofsecurity, and, indeed, replay attacks can easily be leveraged against aport knock server in an effort to masquerade as a legitimate client.Moreover, in port knocking schemes the communication of informationwithin packet headers as opposed to the packet payload severely limitsthe amount of data that can effectively be transferred. The port fieldsof the TCP and UDP headers are 16 bits wide, so only two bytes ofinformation can be transferred per packet in a traditional port knocksequence. This assumes that other fields within the packet header arenot also made significant in terms of the knock sequence, but anyconceivable implementation would not be able to transmit nearly as muchinformation as a protocol that makes use of payload data. If only twobytes of information were all that were required to communicate thedesired access to a portknock daemon then this would not be asignificant issue, but it is not enough to simply create a mappingbetween a knock sequence (however short) and opening a port. Anencryption algorithm can help, but even a symmetric block cipher with areasonable key size of, say, 128 bits forces at least 8 packets to besent at two bytes per packet. As soon as multiple packets becomeinvolved, we need to try to ensure that the packets arrive in order.This implies that a time delay is added between each successive packetin the knock sequence. Simply blasting the packets onto the network asquickly as possible might result in out of order delivery by the timethe packets reach their intended target. Because the knock server isstrictly passively monitoring packets and consequently has no notion ofa packet acknowledgment scheme (such as built into the TransmissionControl Protocol), a reasonable time delay is on the order of about ahalf second. Given a minimum of 8 packets to send, we are up to fourseconds just to communicate the knock sequence. In addition, if therewere ever a need to send more information, say on the order of 100bytes, the time to send would be longer than most people would bewilling to wait.

Unfortunately, under current port-knocking schemes, a consequence ofsending multiple packets in a slow sequence is that it becomes trivialfor an attacker to break any sequence as it is being sent by the portknocking client. All the attacker needs to do is to spoof a duplicatepacket from the source address of the client as a knock while thesequence is in progress. This duplicate packet would be interpreted bythe knock server as part of the sequence, and hence breaking theoriginal sequence. There is existing software (programs like hpingavailable at http://www.hping.org) that makes it exceedingly easy tospoof IP packets from arbitrary IP addresses.

It would be greatly advantageous to provide an authentication andauthorization scheme employing Single Packet Authorization that does notsuffer from this type of easy injection attack. It would also beadvantageous to prevent attackers from replaying captured messagesagainst the knock server. A mechanism should be in place that makes iteasy for the server to know which messages have been sent before and nothonor those that are duplicates of previous messages (it is not enoughjust to encrypt knock sequences as encryption can be deciphered aswell).

There currently are no known traditional port knocking methods thatelegantly prevent replay attacks, though some make it difficult (such asaltering knock sequences based upon time, iterating a hashing functionas in the S/KEY system, or even manually changing the agreed uponencryption key for each successful knock sequence). However, each ofthese known methods requires keeping state at both the client and theserver, and does not scale well once lots of users become involved.

SUMMARY OF THE INVENTION

It is therefore, an object of this invention to provide a method forsecure remote authorization using a single packet authorization (SPA)server on a host system, an SPA client on a client system, and aspecially-formatted SPA packet sent from the client in order to gainaccess to services on the host.

It is another object to provide a method for secure remote authorizationusing a packet format that is encrypted and non-replayable.

It is another object to provide a method for secure remote authorizationin which only a single packet needs to be sent (rather than continuousport-knocking), thereby minimizing the authorization footprint on thenetwork.

It is still another object of the invention to provide a method forsecure remote authorization using specially-formatted SPA packets thatcannot be modified en-route, duplicated, or replayed by a maliciousthird party, thereby thwarting replay attacks.

These and other objects are accomplished herein by a method for securesingle-packet remote authorization using a single packet authorization(SPA) server on a host system that passively monitors a network for avalid SPA packet while maintaining a default deny stance on a gatewaypacket filter, an SPA client on a client system that is responsible forgenerating the appropriately encrypted SPA packet in order to gainaccess to services on the host, and a particular packet format sent fromthe client to the host to gain access. The packet format is encryptedand non-replayable. This non-replayable Single Packet Authorizationmethod facilitates a more elegant solution to the replay problem. EachSPA packet includes 16 bytes of random data in every message, and an MD5sum that is a hash function of the random data (made via any knownhashing function). The MD5 sum is calculated over the entire message andthen used by the SPA server to verify message integrity after asuccessful message decrypt. The SPA server stores the MD5 sum of everyvalid SPA packet that it monitors and flags any duplicate accessattempts. This way, if any SPA packet has the same MD5 hash as apreviously monitored packet, then the SPA server treats the packet asbeing generated by a malicious attempt to replay the original packetagainst the server in an effort to gain the same access.

The present method of network authorization protects arbitrary networkservices by first requiring that a packet filter intercepts and blocksall access to a set of protected services (this interception typicallyhappens within the OS kernel, and hence code paths available to awould-be attacker are minimized). The packet filter is dynamicallyreconfigured after passively monitoring a valid SPA packet. The methodis described and exemplified in the context of an open source projectcalled “fwknop” (which includes both client and server-side components).The SPA authentication packets are logged via the Netfilter ulogd pcapwriter or by sniffing the wire via libpcap, and are encrypted. Thistechnique has several advantages over the current port-knocking methodsof network authentication since only single packets are required, muchlarger messages can be sent (up to the minimum MTU between the clientand server), sequences cannot be busted by a malicious third party, andreplay attacks are easily thwarted.

Other variations and advantages are described in the detaileddescription below.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects, features, and advantages of the present invention willbecome more apparent from the following detailed description of thepreferred embodiments and certain modifications thereof when takentogether with the accompanying drawings in which:

FIG. 1 shows a basic network diagram of the present system.

FIG. 2 illustrates the Single Packet Authorization Message Format.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is a method for secure single-packet remoteauthorization using a single packet authorization (SPA) server on a hostsystem that passively monitors a network for connection attempts andanonymously accept or rejects said attempts, an SPA client on a clientsystem that is responsible for generating the appropriately encryptedSPA packet in order to gain access to services on the host, and aparticular packet format sent from the client to the host to gainaccess. The packet format is encrypted with either a symmetric orasymmetric encryption algorithm, and non-replayable by virtue ofcomparison of MD5 hash values of previously communicated SPA packets.The SPA client and SPA server are components of a firewall knockoperator, and are preferably existing software components hereinidentified as fwknop (“FireWall Knock Operator”), which is programmed toimplement the present method. However, one skilled in the art shouldunderstand that other existing firewall knock operators may beprogrammable in a like manner to serve equally well. There are two majorcomponents to fwknop: an authenticating Ethernet sniffer (fwknopdserver) on the host system that is responsible for modifying a packetfilter that has been configured in a default-drop stance for allprotected services, and an SPA client (fwknop client) on the clientsystem that is responsible for generating the appropriately encryptedSPA packet in order to gain access to services protected by fwknopd.

FIG. 1 shows a basic network diagram of the present system. The fwknopdSPA server 10 is programmed to allow access to a specified port by aspecified username once a valid SPA message is monitored. The fwknopdserver 10 is also programmed to accept each valid SPA message only once(hence “non-repeatability”). Thus, in order for an fwknop SPA client 20to authenticate and allow the subsequent authorization criteria to beapplied, several pieces of information must be securely communicated tothe fwknopd SPA server 10 through an intermediate network. Thus, thepresent method requires a specific Fwknop Single Packet AuthorizationMessage Format (described below). Several other software components arealso required. Specifically, the method requires an existing firewall onthe server 10 side (this technique is compatible with any commercial ornon-commercial firewall or packet filtering architecture), as well as apacket capture library such as libpcap. Netfilter is an existingopen-source packet filtering framework inside the Linux kernel serieswhich enables packet filtering, network address and port translation andother packet manipulation, and the fwknop implementation currentlysupports Netfilter. Netfilter comprises a set of hooks inside the Linuxkernel that allows kernel modules to register callback functions withthe network stack. A registered callback function is then called backfor every packet that traverses the respective hook within the networkstack. Libpcap is a library of code that provides a high level interfaceto allow packet capture. Generally, libpcap implements a virtual devicefrom which captured packets are read from userspace applications. Thisallows a packet filtering mechanism for use as a network trafficanalyzer.

The present system employs Netfilter to intercept (hook) packets withinthe kernel, which are then analyzed and screened using libpcap. Thus,anyone scanning for a service protected by this method cannot even talkdirectly to the IP stack without being authorized. In accordance withthe present invention, Netfilter is set to maintain a “default drop”stance in order to protect services (such as OpenSSH) with an additionallayer of security, thereby making the exploitation of vulnerabilitiesmuch more difficult. The fwknop server 10 passively monitorsauthorization packets via libcap and hence there is no “server” to whichto connect in the traditional sense. Access to a protected service isonly granted after a valid encrypted and non-replayed packet ismonitored.

On the client 20 side, fwknop is used to generate encrypted andnon-replayable IP packets that will be authenticated (both symmetric andasymmetric encryption algorithms are supported) and tested forauthorization (by comparison of username and cryptographically strongsignatures against required Access Control Lists) in order to gainaccess through a packet filter to a protected service. In order for anfwknop SPA client 20 to authenticate and allow the subsequentauthorization criteria to be applied, several pieces of information mustbe securely communicated to the fwknopd SPA server 10. Thus, the presentmethod requires a specific Fwknop Single Packet Authorization MessageFormat by which a client transmits the following within each SPAmessage: 16 bytes of random data local username local timestamp fwknopversion mode (access or command) desired access (or command string) MD5sum

FIG. 2 illustrates the Single Packet Authorization Message Format.

The 16 bytes of random data ensures that each SPA message has aextremely high probability of being unique and hence allows the fwknopdserver to maintain a cache of previously seen messages in order tothwart replay attacks.

The local username enables the fwknop server to distinguish betweenindividual users so that different levels of access can be granted on aper username basis.

The version number allows the fwknop message format to be extended whilepreserving backwards compatibility for older versions of the software.

The mode value instructs the server that the client either wishes togain access to a service or run a command, each of which is specified inthe next field.

The MD5 sum is calculated over the entire message and then used by theserver 10 to verify message integrity after a successful messagedecrypt.

Each of the above values are concatenated together with “:” characters(with base64 encoding applied where necessary so as to not bust thefield separation convention) and then the entire message is encrypted,either by symmetric or asymmetric encryption schemes (preferablyRijndael or GnuPG respectively). The ciphering requires sharing of a keyup to 128 bits (symmetric) or 2048 bytes (asymmetric) in length betweenthe fwknop SPA client and the fwknopd SPA server.

To further illustrate the foregoing method, a practical example will beexplained to illustrate the usage of fwknop in the default Single PacketAuthorization mode to protect and gain access. First, it is necessary toconfigure the fwknop server 10 to allow access to, for example, TCP port22 by, for example, the “mbr” username. This entails the definition ofan fwknopd server configuration file. In the present example bothsymmetric and asymmetric encryption schemes (Rijndael and GnuPGrespectively) will be shown, and so configuration directives that enablean fwknop client to utilize either encryption scheme. The fwknop accessconfiguration file “access.conf” for present purposes is shown below.SOURCE: ANY; DATA_COLLECT_MODE: PCAP; OPEN_PORTS: tcp/22;PERMIT_CLIENT_PORTS: Y; KEY: demokey1; GPG_HOME_DIR: /root/.gnupg;GPG_DECRYPT_ID: 706FBFDD; GPG_DECRYPT_PW: decryptgpgpw; GPG_REMOTE_ID:A742839F; FW_ACCESS_TIMEOUT: 10; REQUIRE_USERNAME: mbr;

Normally, this file is placed at the location /etc/fwknop/access.conf inthe filesystem on the host system where fwknopd runs. The SOURCEvariable describes the IP addresses and/or networks from which SPApackets may be issued (the “ANY” value is a wildcard that allows an SPApacket to be generated from any IP or network). The DATA_COLLECT_MODEvariable informs fwknopd that SPA packets are to be collected vialibpcap by sniffing the wire directly instead of monitoring a file thatis written to by a separate sniffer process or by the Netfilter ulogdpcap writer. The OPEN_PORTS variable defines which specific ports willbe opened in the Netfilter policy after receving a valid SPA packet. ThePERMIT_CLIENT_PORTS variable instructs the fwknopd server to open allTCP and/or UDP ports that are specified by the client in the (encrypted)SPA packet. The KEY variable is most important for the symmetricRijndael encryption algorithm since it defines the shared key betweenthe fwknop client and fwknopd server. On the client side, the user isprompted to enter the shared key before the SPA packet is encrypted andsent on the wire. All variables that begin with “GPG_” describe someaspect of using GnuPG (see: http://www.gnupg.org) as the encryptionmechanism for SPA communications. The GPG_HOME_DIR variable defines thefilesystem path to the GnuPG directory where the fwknopd server key isstored. The GPG_DECRYPT_ID variable defines the key ID of the serverpublic key that will be used by the fwknop client 20, and theGPG_DECRYPT_PW variable defines the password associated with the serverkey (the fwknopd process must be able to decrypt SPA packets on the flyas they are sniffed off the wire). The GPG_REMOTE_ID defines the key IDof the client key that must be used to cryptographically sign the SPAmessage. Note that GnuPG keys must be generated on both the client andserver side for the SPA communication, and each of these keys must beimported (and signed) into the key ring on the opposite side (i.e.server to client and vice versa).

The FW_ACCESS_TIMEOUT variable specifies how long the packet filter willbe configured to allow the IP address specified within the SPA packet toaccess the desired services. Finally, the REQUIRE_USERNAME. variabledescribes the username that must: be executing the fwknop client processon the client operating system (note that this is not cryptographicallystrong, but it is an additional layer of security). One important noteis that while the FW_ACCESS_TIMEOUT variable is used to define theamount of time (in seconds) that the packet filter controlled by fwknopdwill allow connections to be established with a protected service, theremoval of the rule in the packet filter that grants access to theservice does not necessarily remove all access. The packet filter mayemploy a connection tracking mechanism that will allow all packetsassociated with any TCP session that is established during the accesswindow defined by the FW_ACCESS_TIMEOUT value to continue even after thewindow is passed. This is an advantage because communication over longrunning protocols (such as SSH for example) can be maintained, but allother attempts to establish a TCP session with the protected servicewill fail unless a valid SPA packet is monitored by fwknopd.

The following example command executions illustrate the Single PacketAuthorization scheme according to the present invention in operationfrom both the client 20 and host perspectives. Because fwknop currentlysupports the Netfilter firewalling architecture in the Linux kernel, allcommand output below is collected from Linux systems, but the techniqueis equally applicable to other firewall architectures such as CheckPoint FW-1, NetScreen, and Cisco PIX. Note that at the beginning of eachcommand, there is either the string “client” or “server”. These stringsare included in order to inform the reader about where the command isbeing executed (either on the client system 20 to generate the SPApacket, or on the server system 10 to monitor how the packet filterpolicy is modified, etc.).

First, we login to the host system and start fwknopd SPA server by usingthe standard initialization script (requires root access): [server]#/etc/init.d/fwknop start * Starting fwknop ... [ ok ]

Now, we look at the messages that are written to syslog by fwknopd inorder to verify that everything is functioning correctly and fwknopd isready to accept SPA packets: # tail -n 20 /var/log/messages | grepfwknopd Jan 24 18:47:50 server fwknopd: starting fwknopd Jan 24 18:47:50server fwknopd: flushing existing Netfilter IPT_AUTO_CHAIN chains Jan 2418:47:50 server fwknopd: imported p0f-based passive OS fingerprintingsignatures Jan 24 18:47:51 server fwknopd: imported port knocking accessdirectives (1 SOURCE definitions). Jan 24 18:47:51 server fwknopd:imported previous md5 sums from disk cache: /var/log/fwknop/md5sums

The packet filter (Netfilter in our case) on the host system has not yetbeen configured in default-drop mode (to block all SSH connections), sowe do that now, and also add a state rule to allow established TCPconnections to remain active: # iptables -I INPUT 1 -p tcp --dport 22 -jDROP # iptables -I INPUT 1 -p tcp -m state --state ESATABLISHED,RELATED-j ACCEPT

Next, on the client 20 side, it can be demonstrated using existingsoftware such as Nmap that there is no prior access to any SSH server onthe fwknopd firewall (there should only be access after sending a properSPA packet). Nmap (“Network Mapper”) is a free open source utility fornetwork exploration or security auditing. Nmap uses raw IP packets todetermine what hosts are available on the network, what services(application name and version) those hosts are offering, what operatingsystems (and OS versions) they are running, what type of packetfilters/firewalls are in use, and other characteristics. In thefollowing Nmap output, we clearly see that the sshd port, TCP port 22,is “filtered” which means Nmap could not tell if it is open or closed.[client]# nmap -P0 -p 22 server Starting nmap 3.83.DC13 (http://www.insecure.org/nmap/ ) at 2006-01-24 18:50 EST Interestingports on server (10.10.10.1): PORT STATE SERVICE 22/tcp filtered sshNmap finished: 1 IP address (1 host up) scanned in 2.100 seconds

This indicates that indeed the packet filter has been properlyconfigured to disallow all access to sshd since not even a TCPconnection can be established. At this point, the packet filter on theserver 10 is properly configured (there is no access from the client 20system), and fwknopd is running and sniffing the connection for SPApackets. We are ready to now generate the SPA packet against the fwknopdserver in an effort to gain access to sshd.

To generate a packet pursuant to the Single Packet Authorization MessageFormat of the present invention, we startup the fwknop client first in,for example, symmetric encryption mode. The user will be prompted for anencryption key, and must type in the same key that is listed in the KEYvariable in the fwknopd access.conf file described above. The dialog forthis is as follows: [client]$ fwknop -A tcp/22 -s -k server [+] Startingfwknop in client mode. [+] Resolving hostname: server [+] Enter anencryption key. This key must match a key in the file/etc/fwknop/access.conf on the remote system. Encryption Key: [+]Building encrypted single-packet authorization (SPA) message... [+]Packet fields: Random data: 7770617500218631 Username: mbr Timestamp:1138147120 Version: 0.9.6 Action: 1 (access mode) Access: 0.0.0.0,tcp/22MD5 sum: 1uUNjtZ042VPkFZ76HW+NA [+] Sending 128 byte message to10.10.10.1 over udp/62201...

Next, to attempt to establish an SSH connection and successfully login,we type the “hostname” command to show that we actually logged into theserver system: [client]$ ssh server Password: Last login: Tue Jan 2018:47:37 2006 from client [server]$ hostname server

Recall that the access.conf file on the fwknopd server 10 was configuredto remove the packet filter access after ten seconds. This implies thatif we Nmap-analyze the server 10 again from the client 20 after waiting10 seconds we should not be able to detect that sshd is even listening(this can be done from a separate window on the client system so as toleave the existing SSH session intact). The Nmap output is as follows:[client]# nmap -P0 -p 22 server Starting nmap 3.83.DC13 (http://www.insecure.org/nmap/ ) at 2006-01-24 18:55 EST Interestingports on server (10.10.10.1): PORT STATE SERVICE 22/tcp filtered sshNmap finished: 1 IP address (1 host up) scanned in 2.100 seconds

Note that the original session is still active because Netfilter isallowing packets that are part of the original established sessionthrough: [server]$ hostname server

Thus, in the fwknopd server logfile we see the following messages havebeen generated as a result of receiving the valid SPA packet (note thetimestamps which indicate that the firewall ACCEPT rule was indeedremoved after 10 seconds): Jan 24 19:14:56 server fwknopd: receivedvalid Rijndael encrypted packet from: 192.168.20.2, remote user: mbr Jan24 19:14:56 server fwknopd: adding FWKNOP_INPUT ACCEPT rule for192.168.20.2 −> tcp/22 (10 seconds) Jan 24 19:15:07 server knoptm:removed iptables FWKNOP_INPUT ACCEPT rule for 192.168.20.2 −> tcp/22, 10second timeout exceeded

In the log messages above, “FWKNOP_INPUT” refers to the custom Netfilterchain that is built by fwknopd as it runs. All dynamically created rules(with the exception of a jump rule in the Netfilter INPUT chain) areadded and deleted from this chain so as to always keep fwknopd rulesseparate from the existing Netfilter policy.

At this point we can be confident that the fwknop software is bothgenerating SPA messages, encrypting/decrypting them via the symmetricRijndael algorithm, monitoring them as they traverse the network, andmodifying firewall rules to grant access to the desired service for alimited window of time.

The following example reflects the identical scenario, except that thistime GnuPG is used to asymmetrically encrypt and decrypt the SPA packetusing public/private keys.

First we verify with Nmap that we still have no ability to access sshdon the server system (assuming fwknopd removed the ACCEPT rule from theprevious example): [client]# nmap -P0 -p 22 server Starting nmap3.83.DC13 ( http://www.insecure.org/nmap/ ) at 2006-01-24 19:03 ESTInteresting ports on server (10.10.10.1): PORT STATE SERVICE 22/tcpfiltered ssh Nmap finished: 1 IP address (1 host up) scanned in 2.800seconds

With no access to sshd, we now use fwknop in GnuPG mode. The SPA packetis encrypted with the public key identified by the GPG_DECRYPT_IDvariable in access.conf on the server, and cryptographically signed bythe key identified by the GPG_REMOTE_ID variable: [client]$ fwknop -Atcp/22 --gpg-recip 706FBFDD -- gpg-sign A742839F -s -k server [+]Starting fwknop in client mode. [+] Resolving hostname: server [+] Enterthe GPG password for signing key: A742839F GPG signing password: [+]Building encrypted single-packet authorization (SPA) message... [+]Packet fields: Random data: 2360737983054140 Username: mbr Timestamp:1138154925 Version: 0.9.6 Action: 1 (access mode) Access: 0.0.0.0,tcp/22MD5 sum: ZK0yoVWEjLxwE1ioh/bC3g [+] Sending 999 byte message to10.10.10.1 over udp/62201...

An observation should be made about the output above: the packet size ofGnuPG SPA packet is 999 bytes (in bold) whereas the packet size for theRijndael SPA packet was only 128 bytes. The difference is due to themanner in which the respective encryption algorithms work. The former isencrypted with an asymmetric algorithm that utilizes a 2048-bit key size(this was the size of the keys chosen via the “gpg—gen-key” command),whereas the later is symmetrically encrypted with a block cipher thatuses a 16-byte key and operates on 128 byte data blocks. Despite theresulting difference in the SPA packet size, the essential fact remainsthat even the largest SPA packet (assuming a GnuPG key size less than orequal to 2048 bits) fits within the Maximum Transmission Unit (MTU) ofEthernet networks (1500 bytes) and many other wide area networking datalink layer protocols. This allows all required data to be transmittedwithin a single encrypted packet without having to be fragmenteden-route because of intermediate networks with smaller MTU sizes.

After generating the SPA packet, we have access to sshd running on theserver 10. [client]$ ssh server Password: Last login: Tue Jan 2419:15:01 2006 from client [server]$ hostname server

Once again, the following messages are written to syslog by fwknopdindicating that ssh access is permitted for 10 seconds and then removed:Jan 24 21:10:09 server fwknopd: received valid GPG encrypted packet(signed with required key ID: A742839F) from: 192.168.20.2, remote user:mbr Jan 24 21:10:09 server fwknopd: adding FWKNOP_INPUT ACCEPT rule for192.168.20.2 −> tcp/22 (10 seconds) Jan 24 21:10:20 server knoptm:removed iptables FWKNOP_INPUT ACCEPT rule for 192.168.20.2 −> tcp/22, 10second timeout exceeded

One final example illustrates one of the most important features of thefwknop implementation of Single Packet Authorization: non-replayability.The manner in which fwknop constructs an SPA packet includes severalfields (listed in the output of the fwknop client), and as seen in FIG.2 one of these fields contains 16 bytes of random data generated, forexample, by the psuedo random number generator built into the Linuxkernel. This data is generated for each SPA packet, and is almost alwaysguaranteed to be different (subject to the limitations of the psuedorandom number generator) from one fwknop execution to the next. Hence,after the SPA cleartext data is encrypted, the resulting encrypted datais also guaranteed to be unique. The fwknopd server 10 uses this fact tostore an MD5 hash of every valid SPA packet that it monitors. This way,if any SPA packet has the same MD5 hash as a previously monitoredpacket, then the fwknopd server treats the packet as being generated bya malicious attempt to replay the original packet against the server inan effort to gain the same access.

To illustrate how the fwknopd server 10 detects and thwarts such anattack, we Nmap the server one more time to make sure that we currentlydo not have ssh access: [client]# nmap -P0 -p 22 server Starting nmap3.83.DC13 ( http://www.insecure.org/nmap/ ) at 2006-01-24 19:45 ESTInteresting ports on server (10.10.10.1): PORT STATE SERVICE 22/tcpfiltered ssh Nmap finished: 1 IP address (1 host up) scanned in 2.600seconds

We indeed have no access to TCP port 22 on the server, so now we executethe fwknop client 20 with the −v command line switch to put fwknop intoverbose mode:  [client]$ fwknop -A tcp/22 -v -s -k server [+] Startingfwknop in client mode. [+] Resolving hostname: server [+] Enter anencryption key. This key must match a key in the file/etc/fwknop/access.conf on the remote system. Encryption Key: [+]Building encrypted single-packet authorization (SPA) message... [+]Packet fields: Random data: 4955926838601951 Username: mbr Timestamp:1138163068 Version: 0.9.6 Action: 1 (access mode) Access: 0.0.0.0,tcp/22MD5 sum: 0hSxA4xX1iGLSuUbcJ9Z5w [+] Packet data:0QSgOBkbV9AtbK8s7KaZPS9B/6waY7e3aoM7Yhjrq1m6c0Tzze JwCre/qGOPwIJCbs9GQvhGF/9G8fXmsz3LX5xAXFQrVf+YXBJWey6q5VJsnTWAdrQHXRVPA EIZ7UvE [+] Sending128 byte message to 10.10.10.1 over udp/62201...

We should have ssh access at this point, and so we test this: [client]$ssh server Password: Last login: Tue Jan 24 21:10:15 2006 from client[server]$ hostname server

Now, we examine the output of the fwknop command above, and resend thepacket over the network with netcat: [client]$ echo“0QSgOBkbV9AtbK8s7KaZPS9B/6waY7e3aoM7Yhjrq1m6c0TzzeJwCre/qgOPwIJCbs9GQhGF/9G8fXmsz3LX5xAXFQrVf+YXBJWey6q5VJsnTWAdrQHXRVPAEIZ7UvE” | nc -u server 62201

On the server 10, we see the following log message, and no access isgranted to the would-be SPA client: Jan 24 21:11:18 client fwknopd:attempted message replay from: 192.168.20.2

It should now be apparent that it is possible to demonstrate the corefunctionality provided by Single Packet Authorization (SPA) byimplementing it into fwknop. In retrospect, the core functionality ofthe present method is derived from three primary improvements:

1) Setting the default deny stance in a packet filter on all packetsattempting to communicate with a protected service and allowing accessonly to proper SPA packets;

2) The specially constructed encrypted and non-replayable replayablepacket format, and dynamic reconfiguration of the packet filter to allowtemporary access to an IP address (one time only);

3) The encrypted packet is passively monitored off the wire using thestandard libpcap library commonly used in Intrusion Detection Systems.

One skilled in the art should understand that there are some featuresoffered by fwknop that have not been explicitly demonstrated above, suchas SPA packet spoofing, auto-resolution of external NAT address viaexternal website, OpenSSH integration patch, and more. The basicfunctionality may be embellished to additionally incorporate any of theforegoing capabilities as well.

In all such cases it should be apparent that there is passivecommunication of authentication information from the client system tothe host system, with no return of data, and so anyone scanning thetarget system cannot tell that there is anything listening on the portsprotected by the knock server. Moreover, the server side use of a packetfilter intercepts all attempts to connect with the server that are notassociated with a valid port knocking sequence. Consequently, even if anattacker possesses the host system's IP address, TCPs and UDP ports thatserve as the door to the host system, it is all useless since aconnection cannot even be established without first issuing a valid SPApacket. Finally, the non-replayable format of the particular SPA messagedisclosed herein provides the most robust security currently available.

Having now fully set forth the preferred embodiments and certainmodifications of the concept underlying the present invention, variousother embodiments as well as certain variations and modificationsthereto may obviously occur to those skilled in the art upon becomingfamiliar with the underlying concept. It is to be understood, therefore,that the invention may be practiced otherwise than as specifically setforth herein.

1. A method for secure remote authorization using a single packetauthorization (SPA) server on a host system, a SPA client on a clientsystem, and a formatted SPA packet sent from the client in order to gainaccess to services on the host, comprising the steps of: constructing apacket of access code comprising a plurality of bytes of random data anda hash function of the random data; sending said packet to a serverconfigured to allow certain predetermined packets; allowing access tosaid server if said packet matches a predetermined packet; storing thehash function of every allowed packet at the server and preventingaccess for any subsequently sent duplicate packets.
 2. The method forsecure remote authorization according to claim 1, wherein said packetformat is encrypted and non-replayable.
 3. The method for secure remoteauthorization according to claim 2, wherein said SPA packet formatcomprises a plurality of bytes of random data and a hash function of therandom data.
 4. The method for secure remote authorization according toclaim 3, wherein said SPA packet format comprises 16 bytes of randomdata and a hash function of the random data.
 5. The method for secureremote authorization according to claim 4, wherein said hash function ofthe random data comprises an MD5 compression function.
 6. The method forsecure remote authorization according to claim 4, wherein said hashfunction of the random data comprises an MD5 compression functioncalculated over the random data.
 7. The method for secure remoteauthorization according to claim 4, wherein said hash function of therandom data comprises an MD5 compression function calculated over theentire message.
 8. The method for secure remote authorization accordingto claim 6, wherein said SPA server stores the MD5 sum of every validSPA packet that it monitors to prevent duplicate access attempts.
 9. Themethod for secure remote authorization according to claim 8, wherein ifsaid SPA server detects a duplicate SPA packet it treats said packet asa malicious access attempt.
 10. The method for secure remoteauthorization according to claim 9, wherein said SPA client dynamicallyreconfigures each valid SPA packet after granting access.
 11. A systemfor secure single-packet remote authorization, comprising: a singlepacket authorization (SPA) server in communication with a network andconfigured to passively monitor said network for a valid SPA packethaving a predetermined format while maintaining a gateway packet filterin a default deny state; an SPA client on a client system configured togenerate formatted SPA packets in order to gain access to services onthe network; wherein said predetermined SPA format is encrypted andnon-replayable.
 12. The system for secure single-packet remoteauthorization according to claim 11, wherein said SPA packet formatcomprises a plurality of bytes of random data and a hash function of therandom data.
 13. The system for secure single-packet remoteauthorization according to claim 12, wherein said SPA packet formatcomprises 16 bytes of random data and a hash function of the randomdata.
 14. The system for secure single-packet remote authorizationaccording to claim 13, wherein said hash function of the random datacomprises an MD5 compression function.
 15. The system for securesingle-packet remote authorization according to claim 14, wherein saidhash function of the random data comprises an MD5 compression functioncalculated over the random data.
 16. The system for secure single-packetremote authorization according to claim 14, wherein said hash functionof the random data comprises an MD5 compression function calculated overthe entire message.
 17. The system for secure single-packet remoteauthorization according to claim 14, wherein said SPA server stores theMD5 sum of every valid SPA packet that it monitors to prevent duplicateaccess attempts.
 18. The system for secure single-packet remoteauthorization according to claim 12, wherein if said SPA server detectsa duplicate SPA packet it treats said packet as a malicious accessattempt.
 19. The system for secure single-packet remote authorizationaccording to claim 12, wherein said SPA client dynamically reconfigureseach valid SPA packet after granting access.